The present invention relates to an information outputting apparatus for generating and outputting information on musical pieces and/or musical performances stored typically in a standard MIDI (Musical Instrument Digital Interface) file, an information editing apparatus for carrying out necessary editing work on input information on musical pieces and/or musical performances and a recording medium for recording information on musical pieces and/or musical performances.
As a conventional standard of musical-performance data, the MIDI is very popular. With the conventional format, that is, a format of musical-piece/musical-performance data created by utilizing this MIDI information, a musical performance based on musical-performance data recorded and edited by a recording sequencer or recording sequence software for recording and editing the musical-performance data from MIDI information can not be performed by using a playback sequencer or playback sequence software for playing back the musical-performance data if the playback sequencer or playback sequence software is different from the recording sequencer or recording sequence software. In order to solve this problem, a standard MIDI file (referred to hereafter simply as an SMF (Standard MIDI File)) has been made popular.
In recent years, an SMF is used for storing musical-piece/musical-performance data transmitted to equipment such as a communication karaoke system. In a communication karaoke system, musical-piece/musical-performance data presented as an SMF is typically distributed to karaoke playback apparatuses each serving as a terminal by a server through public transmission lines such as telephone lines.
The karaoke playback apparatus is provided with a storage unit for storing typically the distributed musical-piece/musical-performance data and a sequencer and a sound source capable of playing back at least an SMF as musical-piece/musical-performance data. When the user makes a request for a musical piece or a musical performance by carrying out a predetermined operation, the karaoke playback apparatus reads out musical-piece/musical-performance data requested by the user from the storage unit to be played back by the sequencer to generate a MIDI event for driving the sound source. As a result, sound of the requested musical piece is generated for a karaoke.
However, the karaoke user of course has a desire to create an original karaoke typically composed of a medley by editing parts of musical pieces as the user likes within a range with a certain degree of freedom and to sing songs with the created karaoke used as a background.
In the data structure of an SMF, information on a point of time at which a certain MIDI message is generated is included as information on a relative time difference, that is, information on a time difference from typically immediately preceding event data. In consequence, when it is necessary to control a MIDI message generated in a real-time manner in an operation to play back an SMF, control of generation of sound by a MIDI apparatus at a point of time the MIDI message is generated relies on a MIDI message generated in the past. This reliance on a MIDI message generated in the past can be said to hold true of a case in which a MIDI message is generated to drive the sound source on the basis of an SMF. As a result, when editing work described above is carried out on an SMF, a problem described below arises.
Here, as an example, assume that editing work is carried out to create a medley comprising a first chorus of musical piece A and a second chorus of musical piece B concatenated each other to follow the first chorus as shown in FIG. 1. That is to say, pieces of SMF data each indicated by a shaded portion in the figure are linked to each other to form a medley to be reproduced in a playback operation.
A delimiter portion between the first and second choruses of musical piece B is shown in FIG. 2 by a score as musical sound actually generated. As shown in FIG. 2, the last musical sound of the first chorus is tones of a grand piano whereas the initial musical sound of the second chorus following the first chorus is tone of an acoustic guitar.
In the editing work, a position on SMF data in the first chorus of musical piece A and in the second chorus of musical piece B is set as an edit point.
In a MIDI format, a musical-performance part comprises a maximum of 16 channels. In an SMF format, musical-performance data of each channel can be collected in a track. FIG. 3 is a diagram showing a typical structure of musical piece B conforming to the SMF format.
It should be noted that, in order to make the explanation simple, FIG. 3 shows a configuration of musical piece B composed of two bars shown in FIG. 2. To put it in detail, the first chorus of musical piece B starts with the generated sound (a sound length of a dotted half-note) of note C from the first beat with tones of a grand piano whereas the second chorus of musical piece B starts with the generated sound (a sound length of a dotted half-note) of note C from the first beat with tones of an acoustic guitar.
As shown in FIG. 3, as an SMF format, a header chunk is provided at the beginning of a file of a musical piece. A header chunk is an area used for storing basic information on the file. The first 4 bytes of a header chunk are used for storing a chunk type. In the example shown in FIG. 3, the chunk type is represented by `4Dh, 54h, 68h, 64h` where the symbol h indicates a hexadecimal representation. The `4Dh, 54h, 68h, 64h` data represents a chunk type of `MThd` by ASCII (American Standard Code for Information Interchange) characters. The chunk type is followed by 4 bytes representing a data length. The data length is the size of data following the chunk. In the present SMF format, the length of data following the header chunk has a fixed value of `00h, 00h, 00h, 06h` as shown in the figure.
After the data length, a format, the number of tracks and a unit time are each represented by 2 bytes. In the case of a contemporary SMF, 3 types of format are prescribed: format 0, format 1 and format 2. In the 2-byte format area following the data length as described above, one of the format types, namely, format 0, 1 or 2, is described. In the example shown in the FIG. 3, the 2 bytes have values of `00h, 00h` indicating that the type of the format of the file is format 0.
In the 2-byte area for the number of tracks, the number of track chunks following the header chunk is described. In the case of format 0, the file is prescribed by the format as a single-track file. Accordingly, in the example shown in FIG. 3, the number of tracks is prescribed as `00h, 01h`.
The unit-time area specifies the meaning of a delta time which is time information for each event, used in a data section of the track chunk. There are 2 types of time unit of an SMF, namely, a time unit with the location of a delimiter such as a bar or a pause mark on a score used as a reference and a time unit based on a time code of the absolute time. In the example shown in FIG. 3, the former time unit is used. In this case, a resolution per quarter note is indicated. A code of `01h, E0h` used in the example shows a resolution of 480 per quarter note. It should be noted that explanation of the time unit based on a time code of the absolute time is omitted.
A track chunk follows the header chunk described above. A track chunk starts with a 4-byte chunk type followed by a 4-byte area for describing a data length and ends with a data section.
In the example, the 4 bytes of the chunk type of the track chunk have values of `4Dh, 54h, 72h, 6Bh`, ASCII characters representing a chunk type of `MTrk`. The data section of a track chunk has a variable length depending on the contents of data. The length of the data section is described in a data-length area. In the example shown in FIG. 3, the data length is stored as `00h, 00h, 00h, 1Fh` indicating that the data section is 29 bytes long.
Each piece of event information stored in the data section is called an MTrk event. In an SMF, there are 3 types of events that can be stored as an MTrk event, namely, a MIDI event, a SysEx (System Exclusive) event and a meta event.
A MIDI event is an event for storing a MIDI channel message. A MIDI event serves as a substance of musical-performance data. The contents of a MIDI event of an SMF are a sequence of a MIDI message conforming to the MIDI format.
A SysEx event is an event mainly for storing a system-exclusive message in MIDI specifications. A meta event is an event for storing, for example, information related to the whole musical performance and necessary information used by a sequencer of sequence software. The contents of a meta event are not included in the musical-performance data itself.
An MTrk event is a MIDI, SysEx or meta event with a delta time (.DELTA.t) showing information on a time added thereto. That is to say, an MTrk event has one of the following formats:
[Delta time (.DELTA.t)] [MIDI event]
[Delta time (.DELTA.t)] [SysEx event]
[Delta time (.DELTA.t)] [Meta event]
A delta time is information on a time, that is, information on a relative time (time difference information) to an immediately preceding MITrk, which is expressed as a so-called variable-length number. The value of the delta time depends on a value specified as a unit time of the header chunk. In the case of a resolution of 480 per quarter note described above, for example, a delta time of 240 corresponds to an interval of an eighth note. An MTrk event coinciding with an immediately preceding MTrk event has a delta time of 0 added thereto.
It should be noted that a detailed explanation of rules of expressing the variable-length number prescribed in an SMF is omitted. The variable-length number is expressed as an array of minimum required bytes. In the SMF format, the delta time is represented by a minimum of 1 byte to a maximum of 4 bytes.
The data section of the example shown in FIG. 3 comprises a sequence of 7 MTrk events, namely, events 1 to 7.
MTrk event 1 is a MIDI event of a program-change message. The program-change message is represented by `C0h, 00h`. The first byte of the program-change message is a status byte (`C0h`). The high-order 4 bits of the status byte is `Ch` indicating status of the program-change message. The low-order 4 bits (`0h`) of the status byte indicate the number of a channel to which the message is to be transmitted. A data byte of `00h` following the status byte is the number of the program.
MTrk event 1 having such values sets the tones of the grand piano for a channel specified by the low-order 4 bits (`0h`) of the status byte as a sound source specified in conformity with specifications of typically a GM (general MIDI).
MTrk event 2 following MTrk event 1 is a MIDI event of a note-on message with the same timing as MTrk event 1 (delta time=`00h`). MTrk event 2 specifies a note-on for the tones of the grand piano.
It should be noted that a status byte (`90h`) at the head of the MIDI event of the note-on message indicates a note-on message for the tones of the grand piano. Much like MTrk event 1, the high-order 4 bits (`9h`) of the status byte represents the status of the note-on whereas the low-order 4 bits (`0h`) is the number of a message transmission channel. The first data byte (`3Ch`) following the status byte is the number of a note to be generated and the second data byte (`40h`) is a velocity. Here, as a note-off message, a note-on-message status of `00h` is used. A note-on velocity is a speed of playing a keyboard, that is, the volume of sound.
MTrk event 3 is a MIDI event of `C0h, 18h` representing a program-change message. MTrk event 3 has a delta time of `83h, 60h` added thereto. This indicates that MIDI event specifies a switch with timing delayed by the delta time to an acoustic guitar as tones subjected to a note-on for a channel for which the tones of the grand piano is set earlier.
MTrk event 4 is a MIDI event of `90h, 3Ch, 00h` representing a note-on message. MTrk event 4 has a delta time of `87h, 40h` added thereto. This MIDI event specifies a note-off of the tones of the grand piano experiencing a note-on earlier. That is, the third byte of the note-on message normally represents a velocity, however, a code of `00h`, set in the third byte as above allows the message to be interpreted as a note-on message.
MTrk event 5 is a MIDI event of `90h, 3Ch, 40h` representing a note-on message. MTrk event 5 has a delta time of `83h, 60h` added thereto. This MIDI event specifies a note-on for the tones of the acoustic guitar specified earlier by MTrk event 3.
MTrk event 6 is a MIDI event of `90h, 3Ch, 00h` representing a note-on message. MTrk event 6 has a delta time of `8Bh, 20h` added thereto. This MIDI event specifies a note-off for the tones of the acoustic guitar which has entered note-on earlier by MTrk event 5.
MTrk event 7 is a meta event indicating an end of track or an end of file. MTrk event 7 has a delta time of `A1h, 60h` added thereto. This meta event indicates the end of the track chunk or, in the case of format 0, the end of the file. A meta event indicating the end of a track is prescribed to have a value of `FFh, 2Fh, 00h` in the SMF format.
Assume that, in an SMF of musical piece B with a file structure shown in FIG. 3, a position between MTrk events 4 and 5 is set as an edit point shown in FIG. 2. This position is a data position corresponding to a break of sound at which the specification of a note-on and a note-off by the grand piano in the first chorus of musical piece B has been made.
Here assume that, by using the edit point shown in FIG. 3 as a base point, musical piece B is concatenated with musical piece A to follow musical piece A as described earlier by referring to FIG. 1. In this case, MTrk events after the edit point shown in FIG. 3 is concatenated with data at the end of the first chorus of musical piece A. To be more specific, the data section after MTrk event 5 shown in FIG. 3 is concatenated with a MTrk event corresponding to the end of the first chorus of musical piece A.
After the editing work, generation of sound by the acoustic guitar is required in the second chorus from which musical piece B starts. In the case of setting an edit point in MTrk event 5 as shown in FIG. 3, however, MTrk event 3 for storing a program-change message for switching the tones to the acoustic guitar is neglected so that MTrk event 3 does not exist any more at the data section after the editing work.
Assume that a musical performance is played back from an SMF file obtained as a result of the editing work described above. In this case, the tones of sound generated as a part of musical piece B is dependent on a program-change message set in preceding musical piece A with which musical piece B is concatenated. It is thus quite within the bounds of possibility that the tones of sound generated by the instrument initially as the part of musical piece B is not set correctly.
It is therefore quite within the bounds of possibility that a naturally desired musical-performance result can not be obtained due to the fact that some event information of data prior to the editing work is missing from data after the editing work. The missing data may occur on MIDI events other than a program-change message and event information of other types.
As is obvious from the explanation given so far, it is quite within the bounds of possibility that a desired musical-performance result can not be obtained from an SMF gained as a result of some editing work even if an edit point is set properly by considering only a position in an SMF corresponding to a break of sound and the editing work is done by using the edit point as a base point.
In order to solve the problem with regard to a musical performance played back from an SMF obtained as a result of data processing such as the editing work described above, a user who knows the MIDI format and/or the data structure of an SMF either generally uses a tool like editor software or a dedicated sequencer and/or sequence software to carry out the data processing.
Here, in the editing work using a sequencer and/or sequence software with a function of editing an SMF like the one described above, for example, in order to easily obtain coincidence of a delimiter position of data with a delimiter of played back sound obtained as a result of the editing work, it is normally necessary to carry out data preprocessing such as interpretation and development of the original data into a temporary data structure with an unique format different from that of the SMF. It should be noted, however, that such data preprocessing is by no means easy processing. In particular, if processing is required to be carried out concurrently with a playback operation in a real-time manner, the hardware and software must bear a pretty heavy load.
For example, consider the problem encountered in the SMF editing described above by focusing on editing work to create a medley which a user likes in a communication karaoke mentioned earlier. If a function for creating a medley by editing an SMF with simple operations carried out by the user itself is to be provided, the scales of the hardware and the software employed in the playback apparatus will become very large and the cost of the playback apparatus will increase accordingly.